History Of Software Engineering Research Articles

The History of Software Engineering

Grady Booch, one of UML’s original authors, offers his perspective on the history of software engineering. This article is part of a theme issue on software engineering’s 50th anniversary. The Web Extra, a version of the article with an expanded bibliography, is at https://extras.computer.org/extra/mso2018050108s1.pdf.

A Conversation with Barry Boehm: Recollections from 50 Years of Software Engineering

Barry Boehm speaks with IEEE Software about his experiences throughout the history of software engineering. This article is part of a theme issue on software engineerings 50th anniversary.

Behavioral software engineering: A definition and systematic literature review

Throughout the history of software engineering, the human aspects have repeatedly been recognized as important. Even though research that investigates them has been growing in the past decade, these aspects should be more generally considered.The main objective of this study is to clarify the research area concerned with human aspects of software engineering and to create a common platform for future research. In order to meet the objective, we propose a definition of the research area behavioral software engineering (BSE) and present results from a systematic literature review based on the definition.The result indicates that there are knowledge gaps in the research area of behavioral software engineering and that earlier research has been focused on a few concepts, which have been applied to a limited number of software engineering areas. The individual studies have typically had a narrow perspective focusing on few concepts from a single unit of analysis. Further, the research has rarely been conducted in collaboration by researchers from both software engineering and social science.Altogether, this review can help put a broader set of human aspects higher on the agenda for future software engineering research and practice.

Looking for the Holy Grail of Software Development

The history of software engineering has been marked by many famous project failures documented in papers, articles, and books. This pattern of lack of success has prompted the creation of dozens of software analysis, requirements definition, design methods, programming languages, software development environments, and software development processes all promoted as solving "the software problem." What we hear less about are software projects that were successful. This article reports on the findings of an extensive analysis of successful software projects that have been reported in the literature. It discusses the different interpretations of success and extracts the characteristics that successful projects have in common. These characteristics provide software project managers with an agenda of topics to be addressed that will help ensure, not guarantee, that their software project will be successful.

Abstraction in Hardware System Design

The history of software engineering is one of continuing development of abstraction mechanisms designed to tackle ever-increasing complexity. Hardware design, however, is not as current. For example, the two most commonly used HDLs date back to the 1980s. Updates to the standards lag behind modern programming languages in structural abstractions such as types, encapsulation, and parameterization. Their behavioral semantics lag even further. They are specified in terms of event-driven simulators running on uniprocessor von Neumann machines.

Software Components beyond Programming: From Routines to Services

Software engineering (SE) conference in 1968, Doug Mc Ilroy introduced the concept of software components during his keynote speech, Mass-Produced Software Components. That components hold such an esteemed place in SE history should come as no surprise: componentization is a fundamental engineering principle. Top-down approaches decompose large systems into smaller parts-components and bottom-up approaches compose smaller parts components into larger systems. Since 1968, components have played a role in both SE research and practice. For example, components have been an immanent part of software architecture from its early days.2 In 1998, the In ternational Conference on Software Engineering introduced component based software engineering (CBSE) as a specific area within SE at the first workshop on CBSE.

Software engineering education

In this paper I trace the history of software engineering education and focus on some of the key players. I highlight what has been accomplished in degree programs and curricula, conferences and wo...

User experience design

The following sections present the history of software engineering in the 1960's through the 1980's.

Development of Software Engineering: A Research Perspective

In the past 40 years, software engineering has emerged as an important sub-field of computer science and has made significant contribution to the software industry. Now it is gradually becoming a new independent discipline. This paper presents a survey of software engineering development from a research perspective. Firstly, the history of software engineering is reviewed with focus on the driving forces of software technology, the software engineering framework and the milestones of software engineering development. Secondly, after reviewing the past academic efforts, the current research activities are surveyed and new challenges brought by Internet are analyzed. Software engineering researches and activities in China are also reviewed. The work in Peking University is described as a representative.

The state of the practice of software engineering

The article is concerned with the state of the practice of software engineering. The article describes the state of software practice circa late 2003. What it does not do is prescribe what the state of software's practice ought to be. There's a reason for sticking to description rather than prescription. For most of software engineering's history, authors have eagerly told practitioners what they ought to be doing. But rarely have those oughts been predicated on what practitioners actually are doing. The article aims to provide a baseline definition of practice, so that future authors who want to prescribe can at least have a description of what they're prescribing for.

The role of taxonomy in language engineering

To achieve systems that successfully process real–life written and spoken language, a prime need is for taxonomic work that introduces the kind of order and well–definedness into the diversity of linguistic forms and structures that the Linnaean system introduced into the biological realm. The current emphasis on statistically based techniques brings this need into particularly sharp focus. To date, the emphasis within the discipline has tended to be different from this. Computational linguistics has focused more on developing parsing software, for instance, than on defining the target analyses that a parser hits or misses. Enterprises that have discussed standards for language engineering have tended to list sets of approved categories, rather than to specify precise boundaries between categories. There is an analogy with the history of software engineering. Creating software is a relatively glamorous activity, but good software is achieved by postponing the glamour in favour of the plodding work of refining specifications.

Software metrics: successes, failures and new directions

The history of software metrics is almost as old as the history of software engineering. Yet, the extensive research and literature on the subject has had little impact on industrial practice. This is worrying given that the major rationale for using metrics is to improve the software engineering decision making process from a managerial and technical perspective. Industrial metrics activity is invariably based around metrics that have been around for nearly 30 years (notably Lines of Code or similar size counts, and defects counts). While such metrics can be considered as massively successful given their popularity, their limitations are well known, and mis-applications are still common. The major problem is in using such metrics in isolation. We argue that it is possible to provide genuinely improved management decision support systems based on such simplistic metrics, but only by adopting a less isolationist approach. Specifically, we feel it is important to explicitly model: (a) cause and effect relationships and (b) uncertainty and combination of evidence. Our approach uses Bayesian Belief nets, which are increasingly seen as the best means of handling decision-making under uncertainty. The approach is already having an impact in Europe.

A history of software engineering at the National Science Foundation (a personal view)

A history of software engineering at the National Science Foundation (a personal view)

Fifty years of progress in software engineering

In this paper, I describe a new outlook on the history of Software Engineering. I portray large-scale structures within Software Engineering to give a better understanding of the flow of history. I use these large-scale structures to reveal the steady, ongoing evolution of concepts, and show how they relate to the myriad whorls and eddies of change. I also have four smaller, more specific purposes in writing this paper.First, I want to point out that old ideas do not die. In The Mythical Man-Month after 20 Years, Brooks claims "the Waterfall Model is Wrong." But if the Waterfall model were wrong, we would stop arguing over it. Though the Waterfall model may not describe the whole truth, it describes an interesting structure that occurs in many well-defined projects and it will continue to describe this truth for a long time to come. I expect the Waterfall model will live on for the next one hundred years and more.Second, I want to show that the Chaos model, Chaos life cycle, Complexity Gap, and Chaos strategy are part of the natural evolution of Software Engineering. The Chaos model and strategy supersede, but do not contradict, the Waterfall and Spiral models, and the Stepwise Refinement strategy. They are more up to date because they express contemporary issues more effectively, and fit our contemporary situations better. The Chaos model, life cycle, and strategy are equally as important, but not better than, other concepts.Third, I compare the Chaos model, life cycle, and strategy to other models, life cycles, and strategies. This paper can be considered a comparison of the ideas presented in my papers about chaos with other ideas in the field. I avoided comparisons in my other papers because I wanted to define those ideas in their own terms and the comparisons did not further the new ideas.Fourth, I make a few predictions about the next ten years of Software Engineering. The large-scale structures described in this history provide a stronger base for understanding how software engineering will evolve in the future.This paper is laid out as follows. In the first section, I use the flow of water as a metaphor to describe the flow of progress in Software Engineering. I use the Water metaphor to show some of the structures within Software Engineering. The current work builds on top of the historical work, and future work will build on top of current work. In the remaining sections, I describe the waves, streams, and tides that portray the evolution of concepts and technologies in Software Engineering.

Computer-aided software engineering ߞ turning the corner

Software engineers responsible for producing CAE tools have been relying, to the detriment of their product, on primitive design tools. The roots of this puzzle lie in the short history of software engineering as a discipline and the amount of foundation work that has had to be done to establish a proper base from which to build. Sufficient groundwork has now been done to allow software engineers to add a simple extension to existing tools and achieve a fully integrated software engineering system, and thus benefit from the ensuing increases in productivity and reliability.

Computer-aided software engineering — turning the corner

Software engineers responsible for producing CAE tools have been relying, to the detriment of their product, on primitive design tools. The roots of this puzzle lie in the short history of software engineering as a discipline and the amount of foundation work that has had to be done to establish a proper base from which to build. Sufficient groundwork has now been done to allow software engineers to add a simple extension to existing tools and achieve a fully integrated software engineering system, and thus benefit from the ensuing increases in productivity and reliability.